Add local metadata - #178

• Yes, I think it would be nice to put .packit into something like <prefix>/local/<package-name>. Then we separate the actual package data from Packit data.
• Maybe they could just create a prebuild for their own target. Disregarding the prebuilds.toml content. So if we find a prebuild 'match' for a specific target it always works. Alternatively we could only store the correct group of the current target.
• Why would it not be possible to implement version specific conflicts in the register? The conflicts_with field is difficult, because it is metadata, but it's also installation data. I think it might be more practical/nicer to put it in the local metadata, because then we only compare repo metadata and local metadata (so it would be only metadata, not sometimes metadata other times installation/register data). I'm really not sure though.
• I think it's nice to put all repository metadata (which is also currently stored in the register) in the local metadata. Then there is a clear division between the two.

Thank you! I would then suggest implementing the following things:

• The local metadata will get stored in <prefix>/local/<package-name>/<package-version>/<metafile>. Although I'm not fully sure if local is the best choice for the directory name, since /usr/local is a default directory on Unix systems with a different meaning.
• We store the prebuild metadata that is applicable for the current target in the metadata.toml file too.

For conflicts_with, homepage and description, we could add a package local metadata file, however this raises new questions:

• Do we store this local package metadata in <prefix>/local/metadata.toml?
• Do we also refresh this package metadata when a package version is refreshed?
• How do we handle multiple package versions from different repositories here? Their metadata could be different.

We could leave the package local metadata for now, and first try to solve the multiple package versions from different repositories in the current structure.
The conflicts_with could be stored on the package version, instead of the package. But this means we have to refactor the conflict detection code. Another question regarding this is whether we should take action when a new conflicting package is added after refreshing the metadata. Should this trigger an unlink of the current package or conflicting package?